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Summary 

The Space Telecommunications Radio System (STRS) project investigated various software-defined 
radio (SDR) architectures for space. An STRS architecture has been selected that separates the STRS 
operating environment from its various waveforms and also abstracts any specialized hardware to limit its 
effect on the operating environment. The design supports software evolution where new functionality is 
incorporated into the radio. Radio hardware functionality has been moving from hardware -based 
application specific integrated circuits (ASICs) into firmware- and software-based processors such as 
field programmable gate arrays (FPGAs), digital signal processors, (DSPs) and general purpose 
processors (GPPs). 

Use cases capture the requirements of a system by describing how the system should interact with the 
users or other systems (the actors) to achieve a specific goal. The unified modeling language (UML) is 
used to illustrate the use cases in a variety of ways. The top-level use case diagram shows groupings of 
the use cases and how the actors are involved. The state diagrams depict the various states that a system 
or object may be in and the transitions between those states. The sequence diagrams show the main flow 
of activity as described in the use cases. 


1.0 Introduction 

The Space Telecommunications Radio System (STRS) project investigated various software-defined 
radio (SDR) architectures suitable for NASA's missions, which are subject to the constraints of the space 
environment. The STRS architecture (fig. 1) separates the STRS operating environment (OE) from its 
various waveform applications and also abstracts any specialized hardware to limit its effect on the 
operating environment. The STRS OE enables the startup, operation, and teardown of the waveform 
applications. The waveform applications are implemented in firmware and software to transform 
information to or from signals that are transmitted over the air. Separating functionality within the radio 
promotes waveform portability and reuse. 

Use cases capture the requirements of a system by describing how the system should interact with the 
users or other systems (the actors) to achieve a specific goal. The unified modeling language (UML) is 
used to illustrate the use cases in a variety of ways. The top-level use case diagram shows groupings of 
the use cases and how the actors are involved. The use case actors are distinguished by whether they are 
external or internal to the spacecraft and whether they are external to the radio in question. The actors’ 
categories determine their allowed roles in interacting with the radio. 


NAS A/TP— 2008-2 14813 


1 




Figure 1. — STRS radio architecture. 
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Figure 2. — Radio evolution. 

The design expects architecture evolution for each generation of radios. For example, legacy radios 
have been largely hardware-based, residing primarily in application specific integrated circuits (ASICs). 
Figure 2 shows how radios evolve due to advances in hardware technology, where the functionality of 
radios have moved and will move into firmware and software-based processors such as field programmable 
gate arrays (FPGAs), digital signal processors DSPs and general purpose processors (GPPs). 
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The state machine diagrams, also known as state-transition diagrams or even simply state diagrams, 
depict the various states in which a system or object may be and the transitions between those states. The 
sequence diagrams (fig. 3) show the main flow of activity as described in the use cases. The sequence 
diagrams model the dynamic behavior and are helpful to document and validate the logic. 

The processing capability of the SDR provides the opportunity for the radio to implement 
functionality previously limited to the flight computer. The flight computer is assumed to be the only 
entity that can physically turn the power on and off for the radio. The flight computer contains a 
watchdog timer to monitor the health of the radio and cycles power if necessary. The flight computer can 
send commands to the radio. The radio will have a command and control subsystem to validate 
commands and translate them to appropriate method calls. 

The design supports software evolution where new functionality is incorporated into the radio. New 
or modified waveforms may be uploaded as required. Also, new parameters may be set for a waveform. 
When a waveform function becomes a required part of the radio, the waveform is transitioned to a 
service. Waveforms become services by being configured as part of the infrastructure. To make a 
waveform into a service, merely include it in the configuration file used at power on. The configuration 
file may be changed by uploading it as an STRS OE component. Examples of likely functions, eventually 
to become part of the STRS infrastructure, are global positioning system (GPS) or ranging, navigation, 
and dynamic discovery service. 


2.0 Documents 

The requirements of the STRS Reference Implementation design were obtained from the 
Concepts and Functions Review for the STRS, Document No.: 99-P54849D Revision A, also known as 
CFD (Concepts and Functions Document). The CFD was developed by General Dynamics under contract 
with NASA Glenn Research Center. 

Appendix B of this document contains the use cases and high-level sequence diagrams for the STRS 
architecture and includes traceability to the parent CFD requirements. 

POSIX standards are defined in the following two documents: 

(1) ISO/IEC 9945:2003 (IEEE Std 1003.1,2003 Edition) POSIX 

(2) IEEE Std 1003.13-2003 Standardized Application Environment Profile (AEP) — POSIX Realtime 
and Embedded Application Support 

http://ieeexplore.ieee.org/iel5/9307/29578/01342418.pdf?tp=&isnumber=29578&arnumber=1342418 

The key terms defined in appendix B were obtained from the STRS Taxonomy Document, TBD. 
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3.0 Use Case Process 


A use case is a set of scenarios that capture the different ways that external users interact with the 
system to achieve a specific goal. Use cases are textual and are in the following format: 


Use Case Identifier: Example Use Case 

Description: A description of the use case goes here. 

External actors: External actor(s) involved with this specific use case. 

Related use cases: Use cases that are related to this use case by interaction or similarity. 

Precondition: Any precondition that must exist before this use case can occur. Usually the initial RADIO state and WAVEFORM 
state are listed. 

Triggering event: Event that triggers use case. Not all use cases have triggering events 

Main Flow: 

1 . This will be an ordered list of steps necessary to perform interaction. This is the nominal flow. Alternate flows will be 
listed below. 

2. Step 2 

3. Step 3 

4. Step 4 

5. etc. 

Resulting event: If completion of use case results in an event, it is listed here. Usually the resulting RADIO state and 
WAVEFORM state are listed. 

Post condition: Description of the results of the use case interaction. (This is the post condition from the nominal flow.) 

Alternatives: 

(la) This is where alternate flows are identified. The alternative will be identified by the number of the main flow where the 

branch occurs followed by a letter a to z. 

(3 a) This is an alternative flow for step 3. 

(3b) This is an additional alternative flow for step 3. 

(7a-8a) This is an alternative flow for a range of steps from the main flow. 

CFD Requirements: A list of CFD requirements related to this use case. 

Requirement Name 

Requirement Description 

Comments: Comments on use case. 


Use case diagrams provide a graphical representation of the use cases and how they are related to 
external actors and other use cases. 

Figure 4 shows the high-level use case diagram for the STRS radio. Each oval in the diagram 
represents a general kind of interaction between the system and its users. Each of the high-level use cases 
shown in the figure are composed of more detailed use cases that describe the interactions at a finer level 
of detail. This high-level use case only lists the key interactions to give a general overview. Refer to the 
actual use cases starting in 0 for details. 

The users are shown as stick figures both inside and outside the spacecraft system boundary. The 
figure shows three general types of user, “Over the Air,” “STRS Command and Control,” and “Payload”. 
The “Ground Station” and “Other Space Vehicle” actors are a type of Over the Air user. Likewise 
“External Port” and “Flight Computer” are types of STRS Command and Control user. This 
generalization is shown on the diagram with the hollow closed triangular arrow pointing from the specific 
actor to the general actor. 
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The Over the Air user is communicating with or controlling the radio by means of a communication 
channel realized by the STRS radio itself. The STRS Command and Control users are communicating 
with the radio by an onboard interface. Note that a Ground Station may configure a waveform over the air 
directly or could configure a waveform indirectly by sending the command to the onboard flight computer 
by means of another radio. This is why ground station is shown twice. From the perspective of the radio 
the indirect command would be coming from the flight computer. The interaction of the ground station 
and the flight computer shown on the right would be read as the ground station uses the flight computer to 
command the STRS radio. 

Some use cases are followed by a high-level sequence diagram. A sequence diagram is a UML 
diagram that shows the dynamic behavior of the system. For example, see figure 3. The boxes at the top 
represent classes, subsystems, or actors that interact. The vertical lines represent life lines of the 
interacting entities with time progressing downward on the diagram. The horizontal lines represent 


NAS A/TP— 2008-2 14813 


5 




interactions between the participants. The sequence diagrams in this document show interactions at a very 
high level. Design-level sequence diagrams will be created later to illustrate the lower-level interactions 
of the system. 


Glenn Research Center 

National Aeronautics and Space Administration 
Cleveland, Ohio, June, 2008 
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Appendix A — Key Terms in Use Cases 

Application programming interface (API): a formalized set of software calls and routines that can be 
referenced by an application program in order to access supporting system or network services. 

Built-in test (BIT): software used to test whether the STRS radio and all of its subsystems are working 
properly. 

Data publisher: part of the system that transmits data to one or more data subscribers. 

Data subscriber: part of the system that receives data from a data publisher. 

External interface: consists of spacecraft interfaces as well as other interfaces used to process input and 
output data of the radio. 

Flight computer: a separate computer connected to the STRS radio that is used to monitor and control 
the STRS radio. It may contain the Watchdog timer for the STRS radio. 

General purpose module (GPM): a hardware module used for general purpose processing that contains 
the STRS OE. 

Hardware abstraction layer (HAL): a HAL is defined to specify the communication and integration 
specification between physical hardware modules. A HAL is the abstraction of control of the specialized 
hardware. It is the part of the STRS OE that implements the HAL API. 

Over-the-air programming (OTAP): a method of distributing new software updates with the necessary 
settings with which to access services. 

Persistent storage: location in the hardware from which data can be obtained and into which data can be 
stored. It includes nonvolatile memory, hard drives, flash, etc. 

Portable Operating System Interface (POSIX): a family of IEEE standards 1003.n, which describes the 
fundamental operating system services and functions necessary to provide a UNIX-like kernel interface to 
applications. POSIX is not an operating system but is instead the guaranteed programming interfaces 
available to the application programmer. 

Quality of Service (QoS): a networking term that specifies a guaranteed throughput level. (Throughput = 
the amount of data transferred from one place to another or processed in a specified amount of time 
measured in Kbps, Mbps, and Gbps, etc.) 

Real-time operating system (RTOS): an operating system that guarantees a certain capability within a 
specified time constraint. 

Software-defined radio (SDR): a collection of hardware and software technologies that enable 
reconfigurable system architectures for wireless networks and user terminals. SDR provides an efficient 
and comparatively inexpensive solution to the problem of building multimode, multiband, and 
multifunctional wireless devices that can be enhanced using software upgrades. 

Specialized hardware: hardware that may be initialized or controlled using software. STRS specialized 
hardware is controlled using the HAL, and permits certain algorithms or functions to be optimized in 
hardware. Specialized hardware can include FPGA, DSP, ASIC, etc. 

Space Telecommunications Radio System (STRS): the project under which various SDR architectures 
were investigated. 

STRS command source: abstracts the command functionality usually found in the interface to the flight 
computer. 

STRS infrastructure: the portion of the STRS radio that implements the required functionality. Such 
functionality includes configuration and control of STRS waveforms as well as the specialized hardware 
via HAL. 

STRS operating environment (OE): the portion of the STRS radio that contains the STRS 
infrastructure, the POSIX conformant RTOS, HAL, and optionally middleware software. Any STRS 
waveform may only use the POSIX interface and the STRS infrastructure interface to access the required 
functionality. 

STRS radio: an SDR designed for the STRS project whose software requirements include portability and 
open source. It contains waveforms and the STRS OE. 


NAS A/TP— 2008-2 14813 


7 



STRS waveform: a waveform implemented as an executable software application that uses a 
standardized interface to the STRS OE to access the required functionality of the hardware and software. 
Using a standard interface aids portability and reuse. 

Waveform (WF): the set of transformations applied to information that is transmitted over the air and the 
corresponding set of transformations to convert received signals back to their information content. A 
waveform comprises the end-to-end functionality (e.g., modulation, coding, frequency conversion, and 
filtering). 

Watchdog Timer (WDT): software and/or hardware that monitors the health of a system and if a 
problem is detected, takes the appropriate action to restore the system back to health. 
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Appendix B — Acronyms 


AEP 

application environment profile 

API 

application programming interface 

ASIC 

application specific integrated circuit 

BIT 

built-in test 

CFD 

Concepts and Functions Document 

DSP 

digital signal processor 

FPGA 

field programmable gate array 

GPM 

general purpose module 

GPP 

general purpose processor 

GPS 

global positioning system 

HAL 

hardware abstraction layer 

OE 

operating environment 

OTAP 

over-the-air programming 

POSIX 

Portable Operating System Interface 

QoS 

Quality of Service 

RTOS 

real-time operating system 

SDR 

software-defined radio 

STRS 

Space Telecommunications Radio System 

UML 

unified modeling language 

WDT 

Watchdog timer 

WF 

waveform 
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Appendix C — State Diagrams 


C.l Radio State Diagram 



Figure 5. — STRS radio state diagram. 
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C.2 Waveform State Diagram 



Figure 6. — STRS waveform state diagram. 


The upload or removal of a waveform normally happens piecemeal so that the Waveform PARTIAL 
state indicates that only a portion of the waveform is loaded. Additional pieces may be loaded until 
upload is complete, and waveform is in the Waveform LOADED state. Additional pieces may be 
removed until removal is complete and waveform is in the Waveform EMPTY state. 

The instantiate command allocates resources and prepares the waveform for execution. The start 
command begins execution after the waveform is instantiated or stopped. A running waveform can be 
stopped or aborted. The Specialized Hardware can be initialized during either instantiation or start, as 
appropriate. Typically, Specialized Hardware is initialized during instantiation then the start command 
will use the HAL to begin processing. 
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Appendix D — STRS Use Cases 

This appendix contains the use cases and high-level sequence diagrams for the STRS architecture. 

D.l Power On 

Use Case Identifier: Power On 

Description: STRS radio is powered on and goes through initialization. 

External Actors: Flight Computer, (Specialized Hardware via the HAL) 

Related Use Cases: Waveform Instantiation and Waveform Start. 

Precondition: STRS radio is powered off (cold Start with no prior conditions) 

Triggering event: STRS radio is powered on 

Main Flow: 

1. Boot Code executes low-level BIT on GPM hardware. 

2. Boot Code initializes and executes the RTOS image. 

3. RTOS executes BIT. 

4. RTOS initializes and executes the STRS Infrastructure. 

5. STRS infrastructure configures the Flight Computer interface. 

6. STRS infrastructure sends to the Flight Computer STRS INITIALIZING state. 

7. STRS infrastructure loads and initializes the HAL. During HAL initialization STRS Infrastructure reads Specialized 
Hardware configuration and installs identified HAL drivers/BSP. 

8. STRS infrastructure invokes BIT on each Specialized Hardware module via the HAL and writes telemetry to the Flight 
Computer interface 

9. STRS infrastructure logs results of all BIT. 

10. STRS infrastructure reads the STRS Application (waveform or service) configuration file and instantiates and starts 
STRS Applications as specified. See Waveform Instantiation and Waveform Start Use Case. 

1 1 . STRS infrastructure sends to the Flight Computer STRS READY state. 

Resulting event: Flight Computer notified that the STRS radio is in READY state. 

Post condition: STRS radio ready to accept commands from Flight Computer. STRS radio is in READY or STRS FAULT state. 

Alternatives: 

(la) Low-level BIT identifies recoverable failure. Mark condition in RAM and proceed to 2. 

(lb) Low-level BIT identifies unrecoverable failure and does not proceed to 2. HW WatchDog Timer resets CPU. 

(3a) BIT identifies recoverable failure. Mark condition in RAM and proceed to 4. 

(3b) BIT identifies unrecoverable failure and does not proceed to 4. HW WatchDog Timer resets CPU. 

(4a) STRS infrastructure does not initialize properly or is corrupted. HW WatchDog Timer resets CPU. 

(7a-8a) Applicable if Specialized Hardware installed. 

(11a) If BIT test failed, STRS infrastructure sends to the Flight Computer STRS FAULT state. 

If the Flight Computer interface does not initialize or if the hardware has a fault, the flight computer will recognize that the STRS 
Radio is not communicating and will perform a Power Cycle. If state is permanent, the Flight Computer will Power Off module and 
attempt to use Redundant System. 


Requirements: 


Requirement ID 

Name 

CUST13.1 

Power On Reset Testing 

CUST14.1 

Diagnostic Reporting and Action 

CUST22 

Standard Spacecraft Interfaces 

SYS5 

Common Services 

SYS 10.1 

Persistent Storage Capacity 

SYS 12 

Device Diagnostic API 

SYS 15 

Power-on Modes 

SYS15.1 

Default Initialization 

SYS20 

Error and Fault Logs 

SYS29 

RF Module Interface 


Comments: All BIT and periodic background monitoring is provided to Flight Computer interface for telemetry. 
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Figure 7. — Power on sequence. 
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D.2 Power Off 


Use Case Identifier: Power Off 

Description: STRS radio performs orderly shutdown and powers off. 


External Actors: Flight Computer, (Specialized Hardware via the HAL), Waveform 


Related Use Cases: Waveform Stop, Waveform Deallocate, Waveform Abort 

Precondition: STRS radio is in the READY or FAULT state 

Triggering event: Shutdown command received from STRS Command Source 


Main Flow: 

1 . Stop all RUNNING waveforms and services. 

2. Deallocate all INSTANTIATED waveforms and services. 

3. STRS infrastructure releases resources associated with specialized hardware. 

4. STRS infrastructure sends to the Flight Computer STRS SHUTDOWN state. 

5. STRS infrastructure commands HAL and RTOS to shutdown. 

Resulting event: Flight Computer notified that the STRS Radio is in SHUTDOWN state. 
Post condition: STRS radio is powered off. 

Alternatives: 

(la) Abort any waveforms and services that got an error in step 1. 


Requirements: 


Requirement ID 

Name 

CUST14.2 

Network Status Monitoring 

SYS21 

Run-Time State Information 


Comments: 
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Figure 8. — Power off sequence. 


NAS A/TP— 2008-2 14813 


16 






D.3 Waveform Upload 

Use Case Identifier: Waveform Upload 

Description: The STRS radio receives a waveform upload request from the STRS Command Source. It is assumed that the STRS 
radio decrypts and authenticates the files. The STRS Radio stores the received file(s) for installation. The STRS Radio returns any 

nonrepudiation of receipt data to the STRS Command Source. 

External Actors: STRS Command Source 


Related Use Cases: Waveform Instantiate and Waveform Remove 


Precondition: STRS radio is ready to accept commands from STRS Command Source. STRS radio is in READY state. Waveform 
is in the Waveform EMPTY state. 

Triggering event: STRS Command Source requests waveform upload. 

Main Flow: 

1 . STRS infrastructure receives a validated command from STRS Command Source. 

2. STRS infrastructure instantiates and starts a Dedicated Service. The Dedicated Service is in Waveform RUNNING state. 

3. The Dedicated Service obtains waveform fragments, decrypts, and validates each waveform fragment. Note a fragment is 
a partial receipt of the waveform. 

4. The waveform fragments are placed in Persistent storage. STRS Infrastructure marks the waveform as PARTIAL. 

5. Repeat from step 2 until entire waveform is received. 

6. The Dedicated Service provides nonrepudiation of receipt information to the STRS Command Source. 

7. The STRS infrastructure marks the waveform as LOADED. 

Resulting event: 

Post condition: The STRS radio has stored waveform files and the STRS radio continues with its normal operation. STRS radio is 
in READY state. Waveform is in the Waveform LOADED state. Dedicated Service state is dependent upon specific design. 

Alternatives: 

(2a) The Dedicated Service is responsible for handling any timeout error for obtaining the file, partial file resend, or invalid file 
attributes. 

(3a) The Dedicated Service encounters an error while storing the waveform. Errors are logged. 

STRS Command Source or STRS infrastructure may cancel software upload at any time. 

Need to add the ability to restart and continue from PARTIAL state. 


Requirements: 


Requirement ID 

Name 

CUST1 

Multiple Waveform Support 

CUST8 

Remote Reconfiguration 

CUST10.1 

Data Integrity Checks on Uploads 

CUST22 

Standard Spacecraft Interfaces 

SYS8 

Secure Transmissions 

SYS9 

Upload Interfaces 

SYS 10 

File Management 

SYS 10.1 

Persistent Storage Capacity 

SYS24 

Control and Management 

SYS30 

Data and Command Integrity 


Comments: Dedicated Service may need to be started by the STRS infrastructure. Using a service rather than including this 
functionality in the STRS infrastructure gives greater flexibility. 
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Figure 9. — Waveform upload sequence. 
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D.4 STRS OE Upload 

Use Case Identifier: STRS OE Upload 

Description: The STRS Radio receives OE Upload request from the STRS Command Source. It is assumed that the STRS radio 
decrypts and authenticates the files. The STRS radio stores the received file(s) for installation. The STRS Radio returns any 

nonrepudiation of receipt data to the STRS Command Source. 

External Actors: STRS Command Source 


Related Use Cases: Power On 


Precondition: STRS radio ready to accept commands from STRS Command Source. STRS radio is in READY state. 
Triggering event: STRS Command Source requests STRS OE upload. 


Main Flow: 

1 . STRS infrastructure receives a validated command from STRS Command Source. 

2. A Dedicated Service is instantiated and started. The Dedicated Service is in Waveform RUNNING state. 

3. A Dedicated Service obtains new STRS OE component fragments, decrypts, and validates each new STRS OE 
component fragment. Note: a STRS OE component fragment is a partial receipt of the STRS OE component. 

4. The STRS OE component fragments are placed in persistent storage. The new STRS OE component fragments do not 
overwrite the currently running STRS OE. The STRS Infrastructure marks the STRS OE component as PARTIAL. 

5. Repeat from step 2 until entire STRS OE component is received. 

6. The Dedicated Service provides nonrepudiation of receipt information to the STRS Command Source. 

7. The STRS infrastructure marks the new STRS OE component as LOADED. 

8. Repeat for all desired new STRS OE components. 

9. The STRS infrastructure marks the new STRS OE components as available. 

Resulting event: 

Post condition: The STRS radio has stored new STRS OE component files and the STRS radio continues with its normal 
operation. STRS radio is in READY state. The Dedicated Service state is dependent upon specific design. 

Alternatives: 

(2a) The Dedicated Service is responsible for handling any timeout error for obtaining the file, partial file resend, or invalid file 
attributes. 

(3a) The Dedicated Service encounters an error while storing the waveform. Errors are logged. 

STRS Command Source or STRS Infrastructure may cancel software upload at any time. 

Need to add the ability to restart and continue from PARTIAL state. 

Requirements: 


Requirement ID 

Name 

CUST1 

Multiple Waveform Support 

CUST8 

Remote Reconfiguration 

CUST10.1 

Data Integrity Checks on Uploads 

CUST22 

Standard Spacecraft Interfaces 

SYS8 

Secure Transmissions 

SYS9 

Upload Interfaces 

SYS 10 

File Management 

SYS 10.1 

Persistent Storage Capacity 

SYS24 

Control and Management 

SYS30 

Data and Command Integrity 


Comments: This use case is optional because components of the STRS OE may be in ROM. 

Normally this use case is followed by a shutdown, power off, power on sequence. 

Dedicated Service may need to be started by the STRS Infrastructure. Using a service rather than including this functionality in the 
STRS Infrastructure gives greater flexibility. 
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Figure 10. — STRS OE upload sequence. 
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D.5 Waveform Instantiation 

Use Case Identifier: Waveform Instantiation 


Description: The STRS radio receives a Waveform Instantiate request from the STRS Command Source. 


External Actors: STRS Command Source, Waveform 


Related Use Cases: Waveform Upload and Waveform Deallocate 

Precondition: STRS radio is in READY state. Waveform is in Waveform LOADED state. STRS Command Source requests that a 
new waveform can be instantiated. 

Triggering event: Instantiation request from STRS Command Source 

Main Flow: 

1 . STRS infrastructure receives a validated command from STRS Command Source. 

2. STRS infrastructure begins to process request by reading configuration file for waveform. 

3. STRS infrastructure loads the configuration images to the target hardware (either GPP or Specialized Hardware). 

4. STRS infrastructure instantiates the Waveform application. 

5. Waveform uses the STRS infrastructure to establish connections to the Specialized Hardware via the HAL. 

6. Waveform uses the STRS infrastructure to configure the hardware and software components. 

7. STRS infrastructure sends to the STRS Command Source the Waveform Instantiated Status 

Resulting event: 

Post condition: Waveform ready to accept Start command from STRS Command Source. STRS radio is in READY state. 
Waveform is in Waveform INSTANTIATED state. 

Alternatives: 

(l-5a) If an error occurs, STRS infrastructure will take the appropriate error handling actions and inform the STRS Command 
Source. 

(6-7 a) If an error occurs, waveform will take the appropriate error handling actions and inform the STRS Command Source 

Requirements: 


Requirement ID 

Name 

CUST8 

Remote Reconfiguration 

CUST9 

RF Tunability 

CUST17 

Pre-Launch Hardware Configuration 

SYS1 

Layered Open Architecture 

SYS 1.2 

Open Interfaces 

SYS 1.2.1 

Waveform API 

SYS1.2.2 

Device API 

SYS5 

Common Services 

SYS6.1 

Data Coding Support 

SYS6.2 

Modulation Formats 

SYS6.3 

Coherent/Noncoherent Mode Support 

SYS9.1 

Reconfiguration APIs 

SYS 12 

Device Diagnostic API 

SYS20 

Error and Fault Logs 

SYS21 

Run-Time State Information 

SYS24 

Control and Management 

SYS25 

Distributed Functionality 

SYS29 

RF Module Interface 

SYS30 

Data and Command Integrity 


Comments: Resource allocation and teardown responsibility still needs to be determined in the elaboration phase. 
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Figure 11. — Waveform instantiation sequence. 
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D.6 Waveform Start 

Use Case Identifier: Waveform Start 


Description: STRS radio receives a request from the STRS Command Source to start a waveform 


External Actors: STRS Command Source, Waveform 


Related Use Cases: Waveform Instantiate and Waveform Stop 


Precondition: STRS radio is in READY state. Waveform is in Waveform INSTANTIATED state. 
Triggering event: Start Waveform request from STRS Command Source 


Main Flow: 

1 . STRS infrastructure receives a validated command from STRS Command Source. 

2. When waveform uses Specialized Hardware and when HAL has already been configured during Waveform Instantiation, 
STRS infrastructure sends waveform START command to Specialized Hardware via the HAL. 

3. Waveform starts processing. 

4. Waveform sends the waveform RUNNING state to STRS infrastructure. 

5. STRS infrastructure sends to the STRS Command Source Waveform RUNNING state. 

Resulting event: 

Post condition: STRS radio is in READY state. Waveform is in Waveform RUNNING state. 


Alternatives: 

(la) If an error occurs, STRS infrastructure will take the appropriate error handling actions and inform the STRS Command 
Source. 

(2a) When waveform uses Specialized Hardware and when HAL has not been configured during Waveform Instantiation, STRS 
infrastructure configures the HAL and sends waveform START command to Specialized Hardware via the HAL. Optionally, 
configuration may include loading the image to the Specialized Hardware, if it wasn’t already performed during instantiation. 

(2b) If an error occurs, STRS infrastructure will take the appropriate error handling actions and inform the STRS Command 
Source. 

(3 a) If an error occurs, waveform will take the appropriate error handling actions and inform the STRS Command Source via 
STRS infrastructure. 

Requirements: 


Requirement ID 

Name 

CUST8 

Remote Reconfiguration 

CUST9 

RF Tunability 

CUST17 

Pre-Launch Hardware Configuration 

SYS1 

Layered Open Architecture 

SYS 1.2 

Open Interfaces 

SYS 1.2.1 

Waveform API 

SYS1.2.2 

Device API 

SYS5 

Common Services 

SYS6.1 

Data Coding Support 

SYS6.2 

Modulation Formats 

SYS6.3 

Coherent/Noncoherent Mode Support 

SYS9.1 

Reconfiguration APIs 

SYS 12 

Device Diagnostic API 

SYS20 

Error and Fault Logs 

SYS21 

Run-Time State Information 

SYS24 

Control and Management 

SYS25 

Distributed Functionality 

SYS29 

RF Module Interface 

SYS30 

Data and Command Integrity 


Comments: Resource allocation and teardown responsibility still needs to be determined in the elaboration phase. 
Normally the Specialized Hardware is loaded prior to the start command. 
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Figure 12. — Waveform start sequence. 
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D.7 Processor Resource Sharing 


Use Case Identifier: Processor Resource Sharing with Flight Computer 

Description: STRS radio receives a processing request from the Flight Computer to perform a processing workload sharing, e.g., 

perform data compression on a dataset. 

External Actors: Flight Computer, Sharing Application (Dedicated Service) 


Related Use Cases: Waveform Instantiation and Waveform Start 


Precondition: STRS radio is in READY state. The Sharing Application is in Waveform INSTANTIATED state. The Flight 
Computer determines that the mission schedule allows the radio to perform the process sharing services. 

Triggering event: Processing Sharing request received from Flight Computer. 

Main Flow: 

1 . STRS infrastructure receives a validated Process Sharing request from the Flight Computer 

2. The STRS infrastructure determines whether the radio has the capacity to perform the process sharing services. 

3. Sharing Application initiates processing (start processor resource sharing). 

4. Sharing Application sends to the Flight Computer Waveform Running Status 

5. Sharing Application receives a validated data from the Flight Computer or other data source via STRS Infrastructure. 

6. Sharing Application returns results to the Flight Computer or other data sink via STRS Infrastructure. 

7. Repeat from step 3 until processing complete or stop command received. 

8. STRS Infrastructure sends the Sharing Application status to the Flight Computer. 

Resulting event: Processing results are returned to the Flight Computer or designated memory location. 

Post condition: STRS radio is in READY state. Sharing Application state is dependent upon specific design. 


Alternatives: 

(5a) Data received from external interface or memory location. 

(6a) Results sent to external interface or memory location. 

(1-2, 8a) If an error occurs, STRS infrastructure will take the appropriate error handling actions and inform the Flight Computer. 
(3-7a) If an error occurs, Sharing Application will take the appropriate error handling actions and inform the Flight Computer. 


Requirements: 


Requirement ID 

Name 

CUST8 

Remote Reconfiguration 

CUST 1 1 

Processing Power Sharing 

CUST 13.2 

Last Known Configuration 

SYS 9.1 

Reconfiguration APIs 

SYS 10 

File Management 

SYS 11 

Distributed Services 

SYS 12 

Device Diagnostic API 

SYS 13 

Availability 

SYS 13.1 

Process Protection 

SYS 17 

Event Notification 

SYS 17.1 

Configurable Event Responses 

SYS 18 

Background Monitoring 

SYS 18.1 

Run-Time Exception Reporting 

SYS 19 

Default Recovery 

SYS 20 

Error and Fault Logs 

SYS 21 

Run-Time State Information 

SYS 25 

Distributed Functionality 

SYS 30 

Data and Command Integrity 


Comments: 

Process Sharing request is assumed to have fields to indicate the type of processing being requested, the location of the data 
set to be processed, and the destination of the processed data product. Other fields may be required to perform validation or 
processing capture duration, etc. 
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Figure 13. — Processor resource sharing sequence. 
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D.8 Set Waveform Parameter 

Use Case Identifier: Set Waveform Parameter 

Description: STRS radio receives a request from the STRS Command Source to set waveform parameter(s). 


External Actors: STRS Command Source, Waveform 


Related Use Cases: Get waveform parameter 

Precondition: STRS radio is in READY state. The waveform is in Waveform RUNNING state or waveform is in Waveform 
INSTANTIATED state. 

Triggering event: Set Parameter request from STRS Command Source. 

Main Flow: 

1 . STRS infrastructure receives a validated set parameter request. 

2. STRS infrastructure sends a set parameter request to waveform. 

3. The waveform verifies that the parameter(s) are acceptable and configures the resources accordingly optionally via the 
HAL. 

4. The waveform sends status to the STRS infrastructure. 

5. The STRS infrastructure indicates to the STRS Command Source that the waveform has been configured. 

Resulting event: 

Post condition: STRS radio is in READY state. The requested waveform parameter(s) have been set. 


Alternatives: 

(3a) The waveform rejects the parameter(s) and notifies the STRS Command Source that the parameter(s) have been rejected. 


Requirements: 


Requirement ID 

Name 

CUST5 

Network Performance Monitoring 

CUST8 

Remote Reconfiguration 

CUST9 

RF Tunability 

CUST15 

Commanded Built-in-Test and Status Reporting 

CUST18 

Multiple Frequency Bands 

CUST22 

Standard Spacecraft Interfaces 

SYS 10 

File Management 

SYS 10.1 

Persistent Storage Capacity 

SYS24 

Control and Management 

SYS30 

Data and Command Integrity 


Comments: Parameters include frequency, power level, bit rate, etc. 

Multiple parameters may be set, but probably one at a time may be sent to the Specialized Hardware via the HAL. 
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Figure 14. — Set waveform parameter sequence. 
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D.9 Get Waveform Parameter 

Use Case Identifier: Get Waveform Parameter 


Description: STRS radio receives a request from STRS Command Source to get Waveform parameter(s). 


External Actors: STRS Command Source, Waveform 


Related Use Cases: Set Waveform Parameter 


Precondition: STRS radio is in READY state. The waveform is in Waveform RUNNING state or waveform is in Waveform 
INSTANTIATED state. 

Triggering event: Get Parameter request from STRS Command Source. 

Main Flow: 

1 . STRS infrastructure receives a validated get parameter request. 

2. STRS infrastructure sends a get parameter request to waveform. 

3. The waveform verifies and retrieves the parameter(s) optionally via the HAL. 

4. The waveform sends requested parameter(s) to the STRS infrastructure. 

5. The STRS infrastructure returns requested parameters to the controlling STRS Application and/or STRS Command 

Source. 

Resulting event: 

Post condition: STRS radio is in READY state. The requested waveform parameter(s) have been retrieved. 


Alternatives: 

(3a) The waveform rejects the request and notifies the STRS Command Source that the requested parameter does not exist. 


Requirements: 


Requirement ID 

Name 

CUST5 

Network Performance Monitoring 

CUST8 

Remote Reconfiguration 

CUST9 

RF Tunability 

CUST15 

Commanded Built-in-Test and Status Reporting 

CUST18 

Multiple Frequency Bands 

CUST22 

Standard Spacecraft Interfaces 

SYS 10 

File Management 

SYS 10.1 

Persistent Storage Capacity 

SYS24 

Control and Management 

SYS30 

Data and Command Integrity 


Comments: Parameters include frequency, power level, bit rate, etc. 

Multiple parameters may be retrieved, but probably one at a time may be obtain from the Specialized Hardware via the HAL. 
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Figure 15. — Get waveform parameter sequence. 
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D.10 Transmit a Packet 

Use Case Identifier: Transmit a Packet 

Description: A data packet from the Data Publisher or Source is transmitted by a waveform across the communication link. 


External Actors: Data Publisher or Source, External Radio (Receiver), Waveform 


Related Use Cases: Receive a Packet 


Precondition: Radio is in READY state. Waveform is in Waveform RUNNING state. 
Triggering event: Data Source sends a packet. 


Main Flow: 

1 . When the Data Source is separate from the waveform, user data packets that are sent from the Data Source are received by 
the infrastructure. 

2. When the Data Source is separate from the waveform, the infrastructure sends the user data packets to the waveform. 

3. The waveform transforms the user data packets into data packets by any necessary encryption, encoding, modulations, etc. 

4. When waveform uses Specialized Hardware, data packets are sent from the waveform to the infrastructure. 

5. When waveform uses Specialized Hardware, data packets are sent from infrastructure to the Specialized Hardware via the 

HAL. 

6. Status may be returned. 

Resulting event: STRS radio transmits a packet (or packets). 

Post condition: The STRS radio remains in READY state 


Alternatives: 

(l-6a) The waveform detects the occurrence of a fault or alarm (Crypto Alarm, out of lock, over temperature, low output power, 
etc.) and disables transmission and notifies the Data Source and/or STRS Command Source of the fault. 

(l-2b) When the Data Source is not separate from the waveform, the waveform creates the user data packets. 


Nonfunctional requirements: Mission dependent 


Requirements: 


Requirement ID 

Name 

CUST1 

Multiple Waveform Support 

CUST3 

Secure Transmission 

CUST4 

Transparent Network Routing 

CUST9 

RF Tunability 

CUST13 

Automate System Recovery/Initialization 

CUST19 

Multichannel Support 

SYS5.1 

Protocol Support 

SYS6.1 

Data Coding Support 

SYS6.2 

Modulation Formats 

SYS6.3 

Coherent/Noncoherent Mode Support 

SYS6.4 

DSSS Support 

SYS7 

Link Metric Reporting 

SYS26 

Frequency Variability 

SYS27.1 

Independent Data Rate 


Comments: Note that this use case does not address the protocols associated with setting up the link, guaranteeing the packet is 
received correctly, or protocols associated with retransmission. 

The STRS radio may have mission requirements for QoS, routing (point-to-point, broadcast or multicast address). 

STRS Applications may contain combining or parsing of packets into frames, it may contain modification of the packet protocols 
(such as TCP-IP Performance Enhancing Proxies), and may contain encryption. 
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Figure 16. — Waveform transmit a packet sequence. 
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D.ll Receive a Packet 

Use Case Identifier: Receive a Packet 

Description: A data packet provided by an External Radio is received across the communication link by a waveform and provided 

to the Data Subscriber or Sink. 

External Actors: Data Subscriber or Sink, External Radio (Transmitter), Waveform 


Related Use Cases: Transmit a Packet 


Precondition: Radio is in READY state. Waveform is in Waveform RUNNING state. 
Triggering event: Waveform receives a packet from an External Radio 


Main Flow: 

1 . When waveform uses Specialized Hardware, data packets are sent to the infrastructure from the Specialized Hardware via the 
HAL. 

2. When waveform uses Specialized Hardware, data packets are sent to the waveform from the infrastructure. 

3. The waveform transforms the data packets into user data packets by any necessary demodulation, decoding, decryption, etc. 

4. When the Data Sink is separate from the waveform, the waveform sends the user data packets to the infrastructure. 

5. When the Data Sink is separate from the waveform, the infrastructure sends the user data packets to the Data Sink. 

6. Status may be returned. 

Resulting event: A packet (or packets) is received by the Data Sink. 

Post condition: The STRS radio remains in READY state 


Alternatives: 

(l-6a) The waveform detects the occurrence of a fault or alarm (Crypto Alarm, out of lock, over temperature, low output power) 
and disables transmission and notifies the Data Sink of the fault. 

(l-2b) When the Data Sink is not separate from the waveform, the waveform processes the user data packets. 

(l-2c) When the Data Sink is separate from the waveform and the infrastructure cannot process the packet, the infrastructure 
notifies the Data Sink of a dropped packet. 

(3b) The waveform cannot process the packet and notifies the Data Sink of a dropped packet. 

Nonfunctional requirements: Mission dependent 


Requirements: 


Requirement ID 

Name 

CUST1 

Multiple Waveform Support 

CUST3 

Secure Transmission 

CUST4 

Transparent Network Routing 

CUST9 

RF Tunability 

CUST13 

Automate System Recovery/Initialization 

CUST19 

Multichannel Support 

SYS5.1 

Protocol Support 

SYS6.1 

Data Coding Support 

SYS6.2 

Modulation Formats 

SYS6.3 

Coherent/Noncoherent Mode Support 

SYS6.4 

DSSS Support 

SYS7 

Link Metric Reporting 

SYS26 

Frequency Variability 

SYS27.1 

Independent Data Rate 


Comments: Note that this use case does not address the protocols associated with setting up the link, guaranteeing the packet is 
received correctly, or protocols associated with retransmission. 

The STRS radio may have mission requirements for QoS, routing (point-to-point, broadcast or multicast address). 

STRS Applications may contain combining or parsing of packets into frames, it may contain modification of the packet protocols 
(such as TCP-IP Performance Enhancing Proxies), and may contain encryption. 


NAS A/TP— 2008-2 14813 


33 







Figure 17. — Waveform receive a packet sequence. 
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D.12 Waveform Stop 


Use Case Identifier: Waveform Stop 

Description: STRS radio receives a request from the STRS Command Source to stop a waveform. 


External Actors: STRS Command Source, Waveform 


Related Use Cases: Waveform Start 


Precondition: STRS radio is in READY state. The waveform is in Waveform RUNNING state. 
Triggering event: Stop Waveform request from STRS Command Source. 


Main Flow: 

1 . STRS infrastructure receives a validated command from STRS Command Source. 

2. STRS infrastructure sends waveform STOP command. 

3. When waveform uses Specialized Hardware, the waveform uses the STRS infrastructure to send the STOP command to 
the Specialized Hardware via the HAL. 

4. Waveform stops processing. 

5. Waveform acknowledges with waveform stopped message to STRS infrastructure. 

6. STRS infrastructure sends to the STRS Command Source the Waveform INSTANTIATED state. 

Resulting event: 

Post condition: STRS radio is in READY state. Waveform is stopped and is in Waveform INSTANTIATED state and ready to 
receive a Waveform start command or Waveform Deallocate command. 

Alternatives: 

(l-3a) If an error occurs, STRS infrastructure will take the appropriate error handling actions and inform the STRS Command 
Source. 

(4a) If an error occurs, waveform will take the appropriate error handling actions and inform the STRS Command Source. 


Requirements: 


Requirement ID 

Name 

CUST8 

Remote Reconfiguration 

CUST9 

RF Tunability 

CUST17 

Pre-Launch Hardware Configuration 

SYS1 

Layered Open Architecture 

SYS 1.2 

Open Interfaces 

SYS 1.2.1 

Waveform API 

SYS1.2.2 

Device API 

SYS5 

Common Services 

SYS6.1 

Data Coding Support 

SYS6.2 

Modulation Formats 

SYS6.3 

Coherent/Noncoherent Mode Support 

SYS9.1 

Reconfiguration APIs 

SYS 12 

Device Diagnostic API 

SYS20 

Error and Fault Logs 

SYS21 

Run-Time State Information 

SYS24 

Control and Management 

SYS25 

Distributed Functionality 

SYS29 

RF Module Interface 

SYS30 

Data and Command Integrity 


Comments: Resource allocation and teardown responsibility still needs to be determined in the elaboration phase. 
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Figure 18. — Waveform stop sequence. 
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D.13 Waveform Deallocate 


Use Case Identifier: Waveform Deallocation 


Description: STRS radio receives a request from the STRS Command Source to deallocate a waveform. 


External Actors: STRS Command Source, Waveform, (Specialized Hardware via HAL) 


Related Use Cases: Waveform Instantiation 


Precondition: STRS radio is in READY state. The waveform is in Waveform INSTANTIATED state. 
Triggering event: Deallocation request from STRS Command Source 


Main Flow: 

1 . STRS infrastructure receives a validated command from STRS Command Source. 

2. STRS infrastructure sends the Waveform Deallocate request to Waveform. 

3. When waveform uses Specialized Hardware, the waveform uses the STRS infrastructure to release and close connections 
to the Specialized Hardware via the HAL. 

4. Waveform releases resources. 

5. Waveform terminates. 

6. STRS infrastructure releases resources associated with waveform 

7. STRS infrastructure sends to the STRS Command Source Waveform LOADED state. 

Resulting event: 

Post condition: STRS radio is in READY state. The waveform and its resources are deallocated. The waveform is in Waveform 
LOADED state. 

Alternatives: 

(1-7 a) If an error occurs, STRS infrastructure will take the appropriate error handling actions and inform the STRS Command 
Source. 


Requirements: 


Requirement ID 

Name 

CUST8 

Remote Reconfiguration 

CUST9 

RF Tunability 

CUST17 

Pre-Launch Hardware Configuration 

SYS1 

Layered Open Architecture 

SYS 1.2 

Open Interfaces 

SYS 1.2.1 

Waveform API 

SYS1.2.2 

Device API 

SYS5; 

Common Services 

SYS6.1 

Data Coding Support 

SYS6.2 

Modulation Formats 

SYS6.3 

Coherent/Noncoherent Mode Support 

SYS9.1 

Reconfiguration APIs 

SYS 12 

Device Diagnostic API 

SYS20 

Error and Fault Logs 

SYS21 

Run-Time State Information 

SYS24 

Control and Management 

SYS25 

Distributed Functionality 

SYS29 

RF Module Interface 

SYS30 

Data and Command Integrity 


Comments: Resource allocation and teardown responsibility still needs to be determined in the elaboration phase. 
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Figure 19. — Waveform deallocate sequence. 
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D.14 Waveform Abort 


Use Case Identifier: Waveform Abort 

Description: STRS radio receives a request from the STRS Command Source to abort a Waveform. 


External Actors: STRS Command Source, Waveform, [Specialized Hardware via the HAL] 


Related Use Cases: Waveform Stop and Waveform Deallocate 

Precondition: STRS radio is in READY state. The waveform is in Waveform RUNNING state. 
Triggering event: Abort request from STRS Command Source 


Main Flow: 

1. STRS infrastructure receives a validated command from STRS Command Source. 

2. When waveform uses Specialized Hardware, the STRS Infrastructure releases and closes connections to the Specialized 
Hardware via the HAL. 

3. STRS infrastructure terminates threads and or processes associated with the waveform 

4. STRS infrastructure releases resources associated with the waveform. 

5. STRS infrastructure sends to the STRS Command Source Waveform LOADED state. 

Resulting event: 

Post condition: STRS radio is in READY state. Waveform and associated resources released. The waveform is in Waveform 
LOADED state. 

Alternatives: 

(l-5a) If an error occurs, STRS infrastructure will take the appropriate error handling actions and inform the STRS Command 
Source. 


Requirements: 


Requirement ID 

Name 

CUST8 

Remote Reconfiguration 

CUST9 

RF Tunability 

CUST17 

Pre-Launch Hardware Configuration 

SYS1 

Layered Open Architecture 

SYS 1.2 

Open Interfaces 

SYS 1.2.1 

Waveform API 

SYS1.2.2 

Device API 

SYS5 

Common Services 

SYS6.1 

Data Coding Support 

SYS6.2 

Modulation Formats 

SYS6.3 

Coherent/Noncoherent Mode Support 

SYS9.1 

Reconfiguration APIs 

SYS 12 

Device Diagnostic API 

SYS20 

Error and Fault Logs 

SYS21 

Run-Time State Information 

SYS24 

Control and Management 

SYS25 

Distributed Functionality 

SYS29 

RF Module Interface 

SYS30 

Data and Command Integrity 


Comments: 
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Figure 20. — Waveform abort sequence. 
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D.15 Waveform Remove 


Use Case Identifier: Waveform Remove 


Description: The STRS radio receives a request from the STRS Command Source to remove a waveform. The specified waveform 

is deleted from persistent storage. 

External Actors: STRS Command Source 


Related Use Cases: Waveform Upload and Waveform Deallocate 

Precondition: STRS radio ready to accept commands from STRS Command Source. STRS radio is in READY state. Waveform is 
in the Waveform LOADED or PARTIAL state. 

Triggering event: STRS Command Source requests waveform removal. 

Main Flow: 

1 . STRS infrastructure receives a validated command from STRS Command Source. 

2. STRS infrastructure removes a waveform fragment from persistent storage. 

3. STRS infrastructure marks the waveform as PARTIAL state. 

4. Repeat from step 2 until entire waveform is removed. 

5. STRS infrastructure marks the waveform as EMPTY state. 

Resulting event: 

Post condition: The STRS radio has removed waveform file(s), and the STRS radio continues with its normal operation. STRS 
radio is in READY state. The waveform is in the Waveform EMPTY state. 

Alternatives: 

(2a) An error is encountered while removing the waveform. Errors are logged. 


Requirements: 


Requirement ID 

Name 

CUST1 

Multiple Waveform Support 

CUST8 

Remote Reconfiguration 

CUST10.1 

Data Integrity Checks on Uploads 

CUST22 

Standard Spacecraft Interfaces 

SYS8 

Secure Transmissions 

SYS9 

Upload Interfaces 

SYS 10 

File Management 

SYS 10.1 

Persistent Storage Capacity 

SYS24 

Control and Management 

SYS30 

Data and Command Integrity 


Comments: 
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Figure 21. — Waveform remove sequence. 
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D.16 Fault Management 


Use Case Identifier: Fault Management 


Description: STRS radio reacts to failure or subnominal performance as indicated by diagnostic and performance monitoring 


External Actors: Flight Computer, Fault Source 


Related Use Cases: TBD 


Precondition: All states: power on through full operations 
Triggering event: detected error 


Main Flow: 

1 . Determine error severity and error source. 

2. Log original error. 

3. If anomaly is recoverable, corrective action is taken. 

4. Log any corrective actions. 

5. Return status to fault source. 

6. Any change in health is reported to Flight Computer and/or waveform or service. 
Resulting event: Update STRS radio state of current configuration 

Post condition: STRS Radio has recovered fully, is degraded, or in fail-safe mode. 


Alternatives: 

(3-5a) If a recoverable error is repeated treat as FATAL. The number of repetitions required is mission-dependent. 
(3-5b) If the error is FATAL, the STRS radio is configured as required by the mission. 

(3-5c) If the WatchDog timer repeats, use fail-safe mode. 

Requirements: 


Requirement ID 

Name 

CUST5 

Network Performance Monitoring 

CUST10.1 

Data Integrity Checks on Uploads 

CUST13 

Automated System 

CUST13.1 

Power ON Reset Testing 

CUST13.2 

Last Known Configuration 

CUST14.1 

Diagnostic Reporting and Action 

SYS7 

Link Metric Reporting 

SYS9.1 

Reconfiguration APIs 

SYS 12 

Device Diagnostic API 

SYS 13 

Availability 

SYS13.1 

Process Protection 

SYS14 

Default Waveform 

SYS 15 

Power-on Modes 

SYS15.1 

Default Initialization 

SYS 16 

Redundancy 

SYS 17 

Event Notification 

SYS 18 

Background Monitoring 

SYS18.2 

Exception Recovery 

SYS18.3 

SEU Mitigation 

SYS 19 

Default Recovery 

SYS20 

Error and Fault Logs 

SYS21 

Run-Time State Information 

SYS25 

Distributed Functionality 

SYS30 

Data and Command Integrity 


Comments: 
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Figure 22. — Fault management sequence. 
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D.17 Commanded Built-In Test 


Use Case Identifier: Built-In-Test 


Description: STRS radio receives a request from the STRS Command Source to perform a built-in test (BIT). 


External Actors: STRS Command Source 


Related Use Cases: Power On and Waveform Instantiation. 


Precondition: STRS radio ready to accept commands from STRS Command Source. STRS radio is in READY state. 
Triggering event: STRS Command Source request Built-In-Test. 


Main Flow: 

1 . STRS infrastructure receives a validated command from STRS Command Source. 

2. STRS infrastructure requests a BIT from the RTOS. 

3. RTOS performs BIT. 

4. STRS infrastructure invokes BIT on its subsystems. 

5. STRS infrastructure invokes BIT on each Instantiated Waveform. 

6. STRS infrastructure invokes BIT on each Specialized Hardware module via the HAL and writes telemetry to the Flight 
Computer interface. 

7. STRS infrastructure logs results of all BIT. 

8. STRS infrastructure sends results to the Flight Computer. 

Resulting event: Flight Computer notified that the STRS radio is in READY state. 

Post condition: STRS radio ready to accept commands from Flight Computer. STRS Radio is in READY or STRS FAULT state. 


Alternatives: 

(3a) BIT identifies recoverable failure. Mark condition in RAM and proceed to 4. 

(3b) BIT identifies unrecoverable failure and does not proceed to 4. HW WatchDog Timer resets CPU. 

(6a) Applicable if Specialized Hardware installed. 

(8a) If BIT test failed, STRS infrastructure sends to the Flight Computer STRS FAULT state. 

If the hardware has a fault, the flight computer will recognize that the STRS radio is not communicating and perform a Power 
Cycle. If state is permanent, the Flight Computer will Power Off module and attempt to use Redundant System. 


Requirements: 


Requirement ID 

Name 

CUST15 

Commanded BIT and status reporting 

CUST14.1 

Diagnostic Reporting and Action 

CUST22 

Standard Spacecraft Interfaces 

SYS5 

Common Services 

SYS 10.1 

Persistent Storage Capacity 

SYS 12 

Device Diagnostic API 

SYS 15 

Power-on Modes 

SYS15.1 

Default Initialization 

SYS20 

Error and Fault Logs 

SYS29 

RF Module Interface 


Comments: All BIT and periodic background monitoring is provided to Flight Computer interface for telemetry. 
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Figure 23. — Commanded BIT 
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